Using Kamailio for the spark Project??? #14
christoph-v
started this conversation in
Ideas
Replies: 1 comment 1 reply
-
|
See discussion on X3D-public on Electron derivatives for building multiuser
systems.
And below for editing VRML text inside VsCode.
How easy/hard would it be to integrate VRML or X3D DOM player within
Electron, which could be used by Discord or VS code (and other Electron
apps).
Since Discord was mainly for gamers originally, it would be great for
Electron to have X3D. Seems like a good environment for 3D modders.
This may already be mentioned on the X3D-public mailing list:
https://forum.castle-engine.io/t/x3d-classic-highlight-and-snippets-for-vscode/223
The leverage we gain is we don’t have to debug video or voice chat, and we
can focus our efforts on collaborative X3D. If somehow, CGE is added as
well, cool!
I think we have to answer, what is collaborative X3D? Obviously SecondLife
used to be a prime example of multiuser 3D. How can we accomplish
collaborative X3D? Without seriously damage to ourselves?
Can we imagine a collaborative X3D authoring tool in Electron?
John
…On Sat, Apr 16, 2022 at 6:41 AM Christoph VALENTIN ***@***.***> wrote:
The first goal of the spark project is to create the so-called "*Open
Source Conferencing Tool*" (*so-called "Phase 1" of spark*).
However this phase 1 should already target at the far-end goal, i.e.
supporting Network Sensor communication of X3D/VRML scenes.
Therefore, we should consider all requirements that are put on X3D/VRML
Multiuser Scenes so far:
- a. When the X3D/VRML scene is hosted by a W3C Browser, then the
communication shall be compliant to WebRTC/AJAX (refer to following e-mail:
http://web3d.org/pipermail/x3d-public_web3d.org/2019-March/010294.html
)
- b. The multiuser communication should be backward compatible with
classical Web3D browsers and their Network Sensor implementations (BS
Contact, Octaga, ......) as well as server implementations (X3Daemon,
......).
- c. The multiuser communication should be backward compatible with
HLA/DIS implementations
All these requirements lead to the approach we will try to solve the
implementation based on Node.js and WebRTC. Only in case it cannot be
solved, then we will try to use a SIP Server like kamailio.
*To be discussed*
—
Reply to this email directly, view it on GitHub
<#14>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFMJ54MRKBZPIF6M3JDI6DVFKRMXANCNFSM5TSIRMKA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
These questions are too big for the S&P-ARK project, currently. But we can save them for future. I will create a new issue for using Electron. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The first goal of the spark project is to create the so-called "Open Source Conferencing Tool" (so-called "Phase 1" of spark).
However this phase 1 should already target at the far-end goal, i.e. supporting Network Sensor communication of X3D/VRML scenes.
Therefore, we should consider all requirements that are put on X3D/VRML Multiuser Scenes so far:
All these requirements lead to the approach we will try to solve the implementation based on Node.js and WebRTC. Only in case it cannot be solved, then we will try to use a SIP Server like kamailio.
To be discussed
Beta Was this translation helpful? Give feedback.
All reactions